1. Technical Field
The present invention relates generally to computer networks and more particularly to communications within a building automation and control network.
2. Discussion
Networks for building environmental control typically use the American Society of Heating Refrigeration and Air Conditioning Engineers (ASHRAE) Building Automation and Control Network (BACnet) Communications Protocol. The ASHRAE BACnet communications system allows a routing device on the network to build a "routing table" which indicates the next communications hop to any destination network. In large systems where there may be hundreds or thousands of destination networks, it is impractical to store all of the routes in the "routing table" due to the volatile memory needed to keep this information. The BACnet specification ignores this practical limitation.
The BACnet specification has a mechanism for advertising routes that consist of a router broadcasting to all other routers an "I-Am-Router-To-Network" message that indicates that it knows how to reach a particular destination network. This message is used by a receiving router to update its routing table and then it is rebroadcast to other downstream routers which perform the same process. In this way, every router knows how to reach every destination.
For the situation when one of these routers does not have enough room in its routing table to save the next hop to a particular destination, any message it receives to this destination network will be rejected since the router does not know where to forward the message. This situation will cause at least three additional messages to be sent on the network: (1) a message asking to locate the route to the destination network; (2) a message indicating that the network was found; and (3) a retransmission of the original message. This current system is relatively inefficient since many of the "I-Am-Router-To-Network" messages will not be used by a particular router if that router is not needed for sending a message to a destination network.
Another problem arising from the use of the ASHRAE BACnet communications protocol is data being misinterpreted by a remote device communicating with a local device due to changes to the database of the local device. This is possible since in BACnet, data is associated with a named object but referenced by a numeric identifier. Since there is no method to monitor that a name-to-identifier binding is valid, a device could be reconfigured such that a different named object is mapped to a previously used identifier. Other devices that use this identifier to read and write data have no way of knowing that the database has been changed and that the data being referenced is associated with a different object.
For example, the current ASHRAE BACnet communication protocol approach would handle the data operations between device A and device B in the following manner which leads to faulty information being exchanged between the two devices. In this example of the current ASHRAE BACnet approach, device B has a set of objects configured into its database as shown in FIG. 1. Device A would like to read the Supply Air Temperature entry. It does this by binding to the object using a BACnet WhoHas message. The request for this message contains the text "Supply Air Temp 1". The response from device B contains the object identifier of the value 00400001 (in hexadecimal; and in binary the value would be as shown in the entry for the "Supply Air Temp 1" entry in FIG. 1). This response is stored by Device A for later use.
Device A uses 00400001 in a ReadProperty message to read the "Supply Air Temp 1". This message only accepts an object identifier as an argument, it will not accept a text name according to the ASHRAE BACnet approach.
After device A has read the "Supply Air Temp 1" value, the data within device B's database is changed in this example to add a new application. The new database of device B is shown in FIG. 2. This new database has the object "Duct Humidity" with the same instance number as the instance number used in the former database of device B for "Supply Air Temp 1".
Device A uses 00400001 in a ReadProperty message to read the "Supply Air Temp 1", but since the database has been changed, Device B now returns the "Duct Humidity". Device B has no way to know that this was not the object that Device A wanted to read, and Device A does not know that the object identifier for "Supply Air Temp 1" has been changed. Device A may perform faulty operations based upon this faulty information.